Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/controllers/resultsController.js`:
- Around line 82-88: The current branch emits the raw errMsg to Sentry metrics
and only sets Sentry.getCurrentScope().setTag('async_handled_processing_error',
true) in the non-empty branch; instead normalize errMsg into a bounded failure
category (e.g., map error text to a fixed code or type) when calling
Sentry.metrics.count('url_submission.async_processing_failure', 1, { attributes:
{ error_category: ... } }) and ensure suppression is applied consistently by
either setting the 'async_handled_processing_error' tag in both branches or,
better, mark the created MiddlewareError instance itself (e.g., a
handledAsyncProcessing flag/property passed in the third-argument metadata) so
suppression logic can read that marker rather than mutating getCurrentScope().

In `@src/controllers/submitUrlController.js`:
- Around line 42-43: The logs in submitUrlController.js currently send the raw
user-supplied submittedUrl to external sinks (via logger.warn/logger.error and
Sentry), so replace the raw URL with a scrubbed value before logging: add or use
a helper (e.g., redactUrl(url) or hashUrl(url) in utils) that either strips
query strings/sensitive fragments or returns a stable hash/origin+path, then
update the logger.warn/logger.error calls (and any Sentry-related log
attributes) in the submit handler (the submit URL controller where logger.warn
is called) and at the other noted call sites (lines referenced 64-65, 79-80,
86-87, 93-94) to pass the scrubbed value instead of submittedUrl; ensure the
helper is deterministic and does not retain query parameters or sensitive
tokens.
- Around line 91-95: postCheckFailure branch logs omit the funnel event field;
update the failure logging so the logger.warn call in the postCheckFailure
handling includes event: 'url_submission_failure' (the Sentry.metrics.count line
can remain unchanged). Locate the postCheckFailure =
postValidators(headResponse).find(...) and add the event property to the
logger.warn payload (preserve existing keys failure_type, type, submittedUrl) so
exists/restricted403/size failures are recorded under the expected event key.

In `@src/services/datasette.js`:
- Around line 29-30: The metric and log currently use the full Datasette URL
(variable url) which contains encoded SQL and creates high-cardinality metric
labels; update Sentry.metrics.count call to remove url from attributes and
instead use stable dimensions such as database and a short query category/name
(e.g. derive a small queryName from the query or pass queryCategory) and modify
logger.warn (in the runQuery()/runQuery function context) to avoid embedding the
full url in metric attributes—keep url only in the warning message or
strip/obfuscate SQL if you must log it, and ensure
Sentry.metrics.count('datasette_query_errors', 1, { attributes: { database,
queryName } }) is used instead of including url.

In `@src/services/platformApi.js`:
- Line 147: The Sentry.metrics.count call currently tags the counter with the
full request URL (Sentry.metrics.count('platform_api_errors', 1, { attributes: {
url } })), which creates unbounded time series; change it to use bounded
attributes instead (e.g., derive and pass endpoint name/path template, HTTP
status family like 5xx/4xx, and a short failure reason code) so the metric uses
fixed cardinality labels; update the call site in platformApi.js to replace the
url attribute with those bounded attributes (endpoint, statusFamily,
failureReason) while keeping the metric name the same.

---

Nitpick comments:
In `@src/utils/logger.js`:
- Around line 13-25: Replace the custom SentryTransport with Sentry's provided
helper: remove the SentryTransport class and use createSentryWinstonTransport
(or createSentryWinstonTransport(Transport) from Sentry SDK) when building
appTransports so the Sentry transport is instantiated and configured by the SDK;
update appTransports to include new createSentryWinstonTransport({ level: 'warn'
}) (or equivalent factory call) alongside transports.Console and transports.File
and ensure any options previously passed into SentryTransport (e.g., level) are
forwarded to the SDK factory.